#graphql resolver arguments | Explore Tumblr posts and blogs

this-week-in-rust · 3 years ago

Text

This Week in Rust 462

Hello and welcome to another issue of This Week in Rust! Rust is a programming language empowering everyone to build reliable and efficient software. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust or send us a pull request. Want to get involved? We love contributions.

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community

Official

Announcing Rust 1.64.0 | Rust Blog

Newsletters

This Month in Rust GameDev #37 - August 2022

Project/Tooling Updates

rust-analyzer - changelog #148

IntelliJ Rust Changelog #179

Announcing async-dns

Fornjot - Weekly Release - 2022-W39

gitoxide - August: Useful rev-spec parsing and an abstraction for remotes

Getting Started with Seaography - A GraphQL framework for SeaORM

Observations/Thoughts

Internship Projects 2022: Concrete Playback

Why Volvo thinks you should have Rust in your car

Linux embracing Rust will boost robotics community

Better Java logging, inspired by Clojure and Rust

Why Async Rust

Apache APISIX loves Rust! (and me too)

Safe pinned initialization

Enabling Rapid Pulumi Prototyping with Rust

STM32F4 Embedded Rust at the HAL: SPI with the MAX7219 LED Dot Matrix

[audio] Rustacean Station: Ockam with Mrinal Wadhwa

Rust Walkthroughs

Building a Real-Time Web Cipher with Rust, Sycamore and Trunk

Dyn async traits, part 9: call-site selection

Rust 2024...the year of everywhere?

Building Nix flakes from Rust workspaces

Accessing Firebird With Diesel and Rust

Multithreading in Rust

Flutter and Rust combined

Miscellaneous

[DE] CTO von MS Azure: Nehmt Rust für neue Projekte und erklärt C/C++ für überholt!

[DE] Rust Foundation erhält 460.000 US-Dollar und gründet ein Team für Security

[DE] Programmiersprache Rust 1.64 erweitert asynchrone Programmierung mit IntoFuture

[video] Rust & Wasm (Safe and fast web development)

[video] Crust of Rust: Build Scripts and Foreign-Function Interfaces (FFI)

[video] Bevy Basics Reflect

Crate of the Week

This week's crate is serde-transcode, a crate to efficiently convert between various serde-supporting formats

Thanks to Kornel for the suggestion!

Please submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

zerocopy - Test more conditions in GitHub actions

pw-sys - help with CI for one of diesel's dependencies

Ockam - Improve CowStr Display

Ockam - https://github.com/build-trust/ockam/issues/3507

Ockam - Refactor NodeManager constructor

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from the Rust Project

347 pull requests were merged in the last week

add armv5te-none-eabi and thumbv5te-none-eabi targets

compiler-builtins: enable floating point intrinsics for RISCV32 microcontrollers

rustc_transmute: fix big-endian discriminants

allow ~const bounds on non-const functions

allow specializing on const trait bounds

recover from struct nested in struct

recover some items that expect braces and don't take semicolons

make cycle errors recoverable

avoid panicking on missing fallback

require #[const_trait] on Trait for impl const Trait

resolve async fn signature even without body (e.g., in trait)

diagnostics: avoid syntactically invalid suggestion in if conditionals

add help for invalid inline argument

suggest Default::default() when binding isn't initialized

improve error for when query is unsupported by crate

improve the help message for an invalid calling convention

look at move place's type when suggesting mutable reborrow

note if mismatched types have a similar name

note the type when unable to drop values in compile time

miri: don't back up past the caller when looking for an FnEntry span

interpret: expose generate_stacktrace without full InterpCx

inline SyntaxContext in both encoded span representation

introduce mir::Unevaluated

only generate closure def id for async fns with body

use function pointers instead of macro-unrolled loops in rustc_query_impl

separate definitions and HIR owners in the type system

use partition_point instead of binary_search when looking up source lines

skip Equate relation in handle_opaque_type

calculate ProjectionTy::trait_def_id for return-position impl Trait in trait correctly

manually cleanup token stream when macro expansion aborts

neither require nor imply lifetime bounds on opaque type for well formedness

normalize closure signature after construction

normalize opaques with bound vars

split out async_fn_in_trait into a separate feature

support overriding initial rustc and cargo paths

use internal iteration in Iterator comparison methods

alloc: add unstable cfg features no_rc and no_sync

a fn pointer doesn't implement Fn/FnMut/FnOnce if its return type isn't sized

fix ConstProp handling of written_only_inside_own_block_locals

implied_bounds: deal with inference vars

make Condvar, Mutex, RwLock const constructors work with the unsupported impl

make projection bounds with const bounds satisfy const

resolve: set effective visibilities for imports more precisely

add option to deduplicate extern blocks

codegen: implement manuallydrop fields better

optimize array::IntoIter

std: use sync::RwLock for internal statics

stabilize const BTree{Map,Set}::new

constify Default impl's for Arrays and Tuples

constify cmp_min_max_by

constify slice.split_at_mut(_unchecked)

add const_closure, constify Try trait

make ManuallyDrop satisfy ~const Destruct

make from_waker, waker and from_raw unstably const

extend const_convert with const {FromResidual, Try} for ControlFlow

recover error strings on Unix from_lossy_utf8

cargo: add support for relative git submodule paths

cargo: improve errors for TOML fields that support workspace inheritance

cargo: report cmd aliasing failure with more contexts

cargo: error trailing args rather than ignore

cargo: forward non-UTF8 arguments to external subcommands

cargo: make unknown features on cargo add more discoverable

rustdoc: stabilize --diagnostic-width

bindgen: handle no_return attributes

bindgen: remove file added by mistake

clippy: add matches! checking to nonstandard_macro_braces

clippy: fix ICE in needless_pass_by_value with unsized dyn Fn

clippy: fix ICE in unnecessary_to_owned

clippy: fix panic when displaying the backtrace of failing integration tests

clippy: moved derive_partial_eq_without_eq to nursery

clippy: never_loop: fix FP with let..else statements

clippy: nonstandard_macro_braces do not modify macro arguments

clippy: new uninlined_format_args lint to inline explicit arguments

clippy: uninit_vec: fix false positive with set_len(0)

rust-analyzer: add assist to unwrap tuple declarations

rust-analyzer: fix diagnostics not working in enum variant bodies

rust-analyzer: fix operator highlighting tags applying too broadly

rust-analyzer: properly set the enum variant body type from the repr attribute

rust-analyzer: properly support IDE functionality in enum variants

rust-analyzer: use the sysroot proc-macro server for analysis-stats

rust-analyzer: display the value of enum variant on hover

rust-analyzer: type inference for generators

Rust Compiler Performance Triage

Overall a fairly quiet week in terms of new changes; the majority of the delta this week was due to reverting #101620, which was a regression noted in last week's report.

Triage done by @simulacrum. Revision range: 8fd6d03e2..d9297d22

2 Regressions, 7 Improvements, 3 Mixed; 3 of them in rollups 53 artifact comparisons made in total

Full report here

Call for Testing

An important step for RFC implementation is for people to experiment with the implementation and give feedback, especially before stabilization. The following RFCs would benefit from user testing before moving forward:

No RFCs issued a call for testing this week.

If you are a feature implementer and would like your RFC to appear on the above list, add the new call-for-testing label to your RFC along with a comment providing testing instructions and/or guidance on which aspect(s) of the feature need testing.

Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Rust Style Team

Final Comment Period

Every week, the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs

No RFCs entered Final Comment Period this week.

Tracking Issues & PRs

[disposition: merge] Allow transmutes between the same types after erasing lifetimes

[disposition: merge] Add AsFd implementations for stdio lock types on WASI.

[disposition: merge] Tracking Issue for asm_sym

New and Updated RFCs

[updated] Update RFC 2906 to match the implementation

[new] RFC: Aligned trait

[new] RFC: Field projection

Upcoming Events

Rusty Events between 2022-09-28 - 2022-10-26 🦀

Virtual

2022-09-28 | Virtual (London, UK) | Rust London User Group

Rust (Hybrid) Hack & Learn September 2022

2022-09-30 | Virtual (Minneapolis, MN, US) | Minneapolis Rust Meetup

Beginner Rust Open "Office Hours"

2022-10-04 | Virtual (Buffalo, NY, US) | Buffalo Rust Meetup

Buffalo Rust User Group, First Tuesdays

2022-10-05 | Virtual (Indianapolis, IN, US) | Indy Rust

Indy.rs - with Social Distancing

2022-10-05 | Virtual (Stuttgart, DE) | Rust Community Stuttgart

Rust-Meetup

2022-10-06 | Virtual (Nürnberg, DE) | Rust Nuremberg

Rust Nürnberg online #18

2022-10-08 | Virtual | Rust GameDev

Rust GameDev Monthly Meetup

2022-10-11 | Virtual (Dallas, TX, US) | Dallas Rust

Second Tuesday

2022-10-12 | Virtual (Boulder, CO, US) | Boulder Elixir and Rust

Monthly Meetup

2022-10-12 | Virtual (Erlangen, DE) | Rust Franken

Rust Franken Meetup #4

2022-10-12 | Virtual (San Francisco, CA, US) | Microsoft Reactor San Francisco

Getting Started with Rust: Building Rust Projects

2022-10-13 | Virtual (Berlin, DE) | EuroRust

EuroRust (Oct 13-14)

2022-10-15 | Virtual (Nürnberg, DE) | Rust Nuremberg

Deep Dive Session 2 (CuteCopter): Reverse Engineering a tiny drone

2022-10-18 | Virtual (Washington, DC, US) | Rust DC

Mid-month Rustful

2022-10-19 | Virtual (Vancouver, BC, CA) | Vancouver Rust

Rust Study/Hack/Hang-out

2022-10-20 | Virtual (Stuttgart, DE) | Rust Community Stuttgart

Rust-Meetup

2022-10-25 | Virtual (Dallas, TX, US) | Dallas Rust

Last Tuesday

Asia

2022-10-11 | Tokyo, JP | Tokyo Rust Meetup

Cost-Efficient Rust in Practice

Europe

2022-09-28 | London, UK + Virtual | Rust London User Group

Rust (Hybrid) Hack & Learn September 2022

2022-09-29 | Amsterdam, NL | Rust Developers Amsterdam Group

Fiberplane Rust Workshop

2022-09-29 | Copenhagen, DK | Copenhagen Rust group

Rust Hack Night #29

2022-09-29 | Enschede, NL | Dutch Rust Meetup

Going full stack on Rust

2022-09-30 | Berlin, DE | RustFi Hackathon

RustFi Hackathon 30 Sept - 2 Oct

2022-10-02 | Florence, IT + Virtual | RustLab

RustLab Conference 2022 (Oct 2-4)

2022-10-03 | Stockholm, SE | Stockholm Rust

Rust Meetup @Microsoft Reactor

2022-10-04 | Helsinki, FI | Finland Rust Meetup

October meetup

2022-10-06 | Wrocław, PL | Rust Wrocław

Rust Wrocław Meetup #29

2022-10-12 | Berlin, DE | Rust Berlin

Rust and Tell - EuroRust B-Sides

2022-10-13 | Berlin, DE + Virtual | EuroRust

EuroRust (Oct 13-14)

2022-10-18 | Paris, FR | Rust Paris

Rust Paris meetup #53

North America

2022-09-28 | Austin, TX, US | Rust ATX

Rust Lunch

2022-09-29 | Ciudad de México, MX | Rust MX

Zola o como la comunidad de RustMX tiene página

2022-10-13 | Columbus, OH, US | Columbus Rust Society

Monthly Meeting

2022-10-18 | San Francisco, CA, US | San Francisco Rust Study Group

Rust Hacking in Person

2022-10-20 | New York, NY, US | Rust NYC

Anyhow ? Turbofish ::<> / HTTP calls and errors in Rust.

2022-10-25 | Toronto, ON, CA | Rust Toronto

Rust DHCP

Oceania

2022-10-10 | Sydney, NSW, AU | Rust Sydney

Rust Lightning Talks

2022-10-20 | Wellington, NZ + Virtual | Rust Wellington

Tune Up Edition: software engineering management

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Jobs

Please see the latest Who's Hiring thread on r/rust

Quote of the Week

Semver has its philosophy, but a pragmatic approach to versioning is:

– Kornel on rust-users

Thanks to Artem Borisovskiy for the suggestion!

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, cdmistman, ericseppanen, extrawurst, andrewpollack, U007D, kolharsam, joelmarcey, mariannegoldin, bennyvasquez.

Email list hosting is sponsored by The Rust Foundation

Discuss on r/rust

#rust-lang #rust #rustlang #twir #long post

0 notes

sanesquaregg · 2 years ago

Text

What exactly is GraphQL?

GraphQL is a new API standard was invented and developed by Facebook. GraphQL is intended to improve the responsiveness, adaptability, and developer friendliness of APIs. It was created to optimize RESTful API calls and offers a more flexible, robust, and efficient alternative to REST. It is an open-source server-side technology that is now maintained by a large global community of companies and individuals. It is also an execution engine that acts as a data query language, allowing you to fetch and update data declaratively. GraphQL makes it possible to transfer data from the server to the client. It allows programmers to specify the types of requests they want to make.

GraphQL servers are available in a variety of languages, including Java, Python, C#, PHP, and others. As a result, it is compatible with any programming language and framework.

For a better understanding, the client-server architecture of GraphQL is depicted above

No JSON is used to write the GraphQL query. A GraphQL query is transmitted as a string to the server then when a client sends a 'POST' request to do so.

The query string is received by the server and extracted. The server then processes and verifies the GraphQL query in accordance with the graph data model and GraphQL syntax (GraphQL schema).

The GraphQL API server receives the data requested by the client by making calls to a database or other services, much like the other API servers do.

The data is then taken by the server and returned to the client as a JSON object.

Here are some major GraphQL characteristics:

Declarative query language, not imperative, is offered.

It is hierarchical and focused on the product.

GraphQL has excellent type checking. It denotes that inquiries are carried out inside the framework of a specific system.

GraphQL queries are encoded in the client rather than the server.

It has all the attributes of the OSI model's application layer.

GraphQL has three essential parts:

Query

Resolver

Schema

1. Query: The client machine application submitted the Query as an API request. It can point to arrays and support augments. To read or fetch values, use a query. There are two key components to a query:

a) Field: A field merely signifies that we are requesting a specific piece of information from the server. The field in a graphQL query is demonstrated in the example below. query { employee { empId ename } } "data": { "employee”: [ { "empId": 1, "ename": "Ashok" }, { "id": "2", "firstName": "Fred" } …] } }

In the above In the GraphQL example above, we query the server for the employee field along with its subfields, empId and ename. The data we requested is returned by the GraphQL server.

b) Arguments: As URL segments and query parameters, we can only pass a single set of arguments in REST. A typical REST call to obtain a specific profile will resemble the following: GET /api'employee?id=2 Content-Type: application JSON { "empId": 3, "ename": "Peter." }

2. Resolver: Resolvers give instructions on how to translate GraphQL operations into data. They define resolver routines that convert the query to data.

It shows the server the location and method for fetching data for a certain field. Additionally, the resolver distinguishes between API and database schema. The separated information aids in the modification of the database-generated material.

3. Schema: The heart of GraphQL implementation is a schema. It explains the features that the clients connected to it can use.

The benefits of using GraphQL in an application are summarized below.

It is more precise, accurate, and efficient.

GraphQL queries are simple and easy to understand.

Because it uses a simple query, GraphQL is best suited for microservices and complex systems.

It makes it easier to work with large databases.

Data can be retrieved with a single API call.

GraphQL does not have over-fetching or under-fetching issues.

GraphQL can be used to discover the schema in the appropriate format.

GraphQL provides extensive and powerful developer tools for query testing and documentation.

GraphQL automatically updates documentation in response to API changes.

GraphQL fields are used in multiple queries that can be shared and reused at a higher component level.

You have control over which functions are exposed and how they operate.

It is suitable for rapid application prototyping.

GraphQL can be used in all types of mobile and web applications across industries, verticals, and categories that require data from multiple sources, real-time data updates, and offline capabilities. Here is some application that benefits greatly from GraphQL development:

It offers Relay as well as other client frameworks.

GraphQL assists you in improving the performance of your mobile app.

It can reduce the problem of over fetching to reduce server-side cloud service and client-side network usage.

It can be used when the client application needs to specify which fields in a long query format are required.

GraphQL can be fully utilized when adding functionality to an existing or old API.

It is used to simplify complicated APIs.

The mix-and-match façade pattern, which is popular in object-oriented programming.

When you need to combine data from multiple sources into a single API.

GraphQL can be used as an abstraction on an existing API to specify response structure based on user requirements.

In this blog, I’ve attempted to explain the significance of GraphQL it is a new technology that allows developers to create scalable APIs that are not constrained by the limitations of REST APIs. It allows developers to use an API to easily describe, define, and request specific data. Please let us know what you think of GraphQL. Do you have any further questions? Please do not hesitate to contact us. We will gladly assist you.

0 notes

ashutecblog · 4 years ago

Text

GraphQL Vs REST: Which One’s Best for API Development?

GraphQL is referred to as the revolutionary choice for API design and development. It presents a modern approach over the traditional REST approach for data sending and retrieval over HTTP. Since the REST has been here for a long time now, it has a high rate of adoption while GraphQL is a better alternative that overcomes the shortcomings of REST.

The argument which one is best for API development is getting intense as the users of both technologies are participating in this raging war. It has left businesses confused about which API design, development, and deployment is better suited for them. The team at ashutec sheds light on which API development technology is best to help businesses make a better decision for their project. But first, let’s understand what an API is.

What is an API?

Application Programming Interface or API is a group of protocols to aid in data sending and retrieval in an easy manner. It simplifies the communication between two systems of an app and helps them talk to each other.

REST and GraphQL both are prominent technologies behind API design and development. Both the technologies resolve the same problem but with a different approach. Here are some criteria to choose the best technology for your API development projects.

1. Community Popularity

2. Performance

3. Security

4. Data Fetching

Read the rest of the article on the best API development technology out of GraphQL and REST to get a better perspective to consider the best technology.

#graphql #code #programming #api #api development

0 notes

weekinethereum · 7 years ago

Text

July 26, 2018

News and Links

Protocol (with an assist from the Ethereum Research team)

Shasper chain, v2.1

Prysmatic’s biweekly update on transitioning to Eth 2.0 with separate Go codebase

VDFs are not Proof of Work by Danny Ryan. Verifiable Delay Functions have some properties - requiring significant computation to calculate but relatively little computation to verify - that is suitable for strengthening RANDAO-based RNG. That sounds like proof of work, but Danny explains the difference between VDFs and PoW.

STARKs, Part 3: Into the Weeds by Vitalik Buterin: In Vitalik’s STARKs series part 3, he introduced how to actually implement a STARK with vivid explication.

Latest Casper standup call

VB: Epoch-less Casper FFG liveness/safety argument

Why Shasper makes more sense than the previous FFG, then sharding roadmap

LearnPlasma is really coming together as a Plasma education resource

A Plasma Cash primer from Simon de la Rouviere

Jinglan Wang: what is Plasma? Plasma Cash?

Raiden is live on Ropsten testnet and open to testing

Stuff for developers

Benchmarking between Mythril, Manticore and Oyente from ConsenSys Diligence

What FoMo3d’s real exit scam might look like, but you can hedge with Augur?

Péter Szilágyi: How to PWN FoMo3D, a beginners guide

Pipeline - video explaining PoC of visual IDE of already deployed functions

Airswap tutorial on building with their API server

Adding ENS into your dapp tutorial

Tutorial to using Parity’s Secret Store multi-party key generation

IDEO on dealing with gas in UX

ethereum-to-graphql: autogenerate the schema and resolver

EthQL alpha from PegaSys and Infura

Aragon Package Manager - upgradeability for Aragon orgs

Zeppelin: Exploring upgradeability governance in ZeppelinOS with a Gnosis MultiSig

Apache Camel connector for Ethereum enterprise using web3j

The new Infura dashboard - existing access tokens need to migrate to v3 authentication keys and endpoints

Release

Trinity v0.1.0-alpha.12, better syncing and performance. Also has a new website.

web3j v3.5

web3.js 0.20.7 and web3.js 1.0.0-beta.35. breaking change on http provider

EthereumJS VM v2.4.0 (and their monthly recap)

Live on mainnet

iExec went live on mainnet to test rendering. 80% of jobs completed.

Melonport is live on mainnet with somewhat constrained Paros release

Gnosis DutchX contracts are live on mainnet in advance of their 100k competition to build on them

Ecosystem

The new Gnosis Safe miltisig is live on Rinkeby

Parity’s Thibaut Sardan: what is a light client and why should you care?

Someone managed to briefly cause a kerfuffle with a 1337 Javascript popup in Etherscan using their Disqus comments.

Nathan Sexer: State of stablecoins

Metamask’s retrospective on getting removed from the Chrome store this week. Also how they’ll support more networks

A reader friendly version of 100+ Eth dev interviews from EthPrize

Governance and Standards

EIP1227 (remove difficulty bomb, revert to 5 ETH block reward) vs EIP1234 (delay difficulty bomb, reduce to 2 ETH block reward) vs EIP1240 (remove difficulty bomb, leave at 3 ETH block reward). Results in Afri’s poll mirror what I hear in the community.

ERC1257: proof of payment standard

ERC1238: non-transferrable token badges

ERC1261: membership verification token

Add bottom-up composables to ERC998

ERC1263: NFT index

Project Updates

As planned, Augur burned the escape hatch, so the code is now decentralized.

Messari buys OnchainFX, lays out content strategy

Status now displays at full resolution on tablets, and no more Mixpanel

Maker to vote on increasing the Dai stability fee to 2.5%

Interviews, Podcasts, Videos, Talks

Dappcon videos are coming in

Andy Tudhope talks about EthPrize’s dev interviews on Smartest Contract

CoinTelegraph with some good print interviews: Jutta Steiner and Joe Lubin

FunFair’s Jez San podcast interview

Open Source Web3 Design call

Jay Rush talking The Dao and how Quickblocks grew out of that from Gitcoin’s weekly stream

Dan Boneh on the Bitcoin Podcast

Ethan Buchman talks testnets on Zero Knowledge

Dan Finlay on MetaMask and Mustekala on Smartest Contract

Maker’s Rune Christensen print interview where he says they are developing their own language for better security

Martin Becze on Epicenter

Tokens

You now need Santiment tokens to access some of their market and data feeds.

Text tutorial of how to claim your (free) Livepeer tokens.

Incentivizing new users of TCRs through gamification

Mike Maples: Slow money crypto

General

Zilliqa releases its Scilla language “with formalization of its semantics and its embedding into Coq.” Also of interest, Etheremon is planning to have gameplay on Zilliqa but will use Ethereum as its store of value.

First Polkadot parachain deployed in PoC2

Raul Jordan with an intro to hashing algos

NYTimes on art and blockchain

Péter Szilágyi: TOR from within GO. I imagine many who read it will immediately start using the Brave browser’s private tabs with TOR

Ethereum coming to Google Cloud

John Backus with his lessons learned from p2p file sharing

Dates of Note

Upcoming dates of note:

August 7 - Start of two month distributed hackathon from Giveth, Aragon, Swarm City and Chainshot

August 10-12 - EthIndia hackathon (Bangalore)

August 10-12 - ENS workshop and hackathon (London)

August 22 - Maker DAO ‘Foundation Proposal’ vote

August 24-26 - Loom hackathon (Oslo, Norway)

September 6 - Security unconference (Berlin)

September 7-9 - EthBerlin hackathon

September 7-9 - WyoHackathon (Wyoming)

September 8 - Ethereum Industry Summit (Hong Kong)

Oct 5-7 - TruffleCon in Portland

Oct 5-7 - EthSanFrancisco hackathon

Oct 11 - Crypto Economics Security Conf (Berkeley)

Oct 22-24 - Web3Summit (Berlin)

Oct 26-28 - Status hackathon (Prague)

Oct 29 - Decentralized Insurance D1Conf (Prague)

Oct 30 - Nov 2 - Devcon4 (Prague)

Dec 7-9 - dGov distributed governance conf (Athens)

December - EthSingapore hackathon

If you appreciate this newsletter, thank ConsenSys

This newsletter is made possible by ConsenSys, which is perpetually hiring if you’re interested.

Editorial control is 100% me. If you're unhappy with editorial decisions, feel free to tweet at me.

Shameless self-promotion

Link: http://www.weekinethereum.com/post/176336020338/july-26-2018

Most of what I link to I tweet first: @evan_van_ness

Did someone forward this email to you? Sign up to receive the weekly email (box in the top blue header)

#ethereum #buidl #Cryptocurrency #web3 #web 3.0

1 note · View note

t-baba · 6 years ago

Photo

Building a Habit Tracker with Prisma, Chakra UI, and React

In June 2019, Prisma 2 Preview was released. Prisma 1 changed the way we interact with databases. We could access databases through plain JavaScript methods and objects without having to write the query in the database language itself. Prisma 1 acted as an abstraction in front of the database so it was easier to make CRUD (create, read, update and delete) applications.

Prisma 1 architecture looked like this:

Notice that there’s an additional Prisma server required for the back end to access the database. The latest version doesn’t require an additional server. It's called The Prisma Framework (formerly known as Prisma 2) which is a complete rewrite of Prisma. The original Prisma was written in Scala, so it had to be run through JVM and needed an additional server to run. It also had memory issues.

The Prisma Framework is written in Rust so the memory footprint is low. Also, the additional server required while using Prisma 1 is now bundled with the back end, so you can use it just like a library.

The Prisma Framework consists of three standalone tools:

Photon: a type-safe and auto-generated database client ("ORM replacement")

Lift: a declarative migration system with custom workflows

Studio: a database IDE that provides an Admin UI to support various database workflows.

Photon is a type-safe database client that replaces traditional ORMs, and Lift allows us to create data models declaratively and perform database migrations. Studio allows us to perform database operations through a beautiful Admin UI.

Why use Prisma?

Prisma removes the complexity of writing complex database queries and simplifies database access in the application. By using Prisma, you can change the underlying databases without having to change each and every query. It just works. Currently, it only supports mySQL, SQLite and PostgreSQL.

Prisma provides type-safe database access provided by an auto-generated Prisma client. It has a simple and powerful API for working with relational data and transactions. It allows visual data management with Prisma Studio.

Providing end-to-end type-safety means developers can have confidence in their code, thanks to static analysis and compile-time error checks. The developer experience increases drastically when having clearly defined data types. Type definitions are the foundation for IDE features — like intelligent auto-completion or jump-to-definition.

Prisma unifies access to multiple databases at once (coming soon) and therefore drastically reduces complexity in cross-database workflows (coming soon).

It provides automatic database migrations (optional) through Lift, based on a declarative datamodel expressed using GraphQL's schema definition language (SDL).

Prerequisites

For this tutorial, you need a basic knowledge of React. You also need to understand React Hooks.

Since this tutorial is primarily focused on Prisma, it’s assumed that you already have a working knowledge of React and its basic concepts.

If you don’t have a working knowledge of the above content, don't worry. There are tons of tutorials available that will prepare you for following this post.

Throughout the course of this tutorial, we’ll be using yarn. If you don’t have yarn already installed, install it from here.

To make sure we’re on the same page, these are the versions used in this tutorial:

Node v12.11.1

npm v6.11.3

npx v6.11.3

yarn v1.19.1

prisma2 v2.0.0-preview016.2

react v16.11.0

Folder Structure

Our folder structure will be as follows:

streaks-app/ client/ server/

The client/ folder will be bootstrapped from create-react-app while the server/ folder will be bootstrapped from prisma2 CLI.

So you just need to create a root folder called streaks-app/ and the subfolders will be generated while scaffolding it with the respective CLIs. Go ahead and create the streaks-app/ folder and cd into it as follows:

$ mkdir streaks-app && cd $_

The Back End (Server Side)

Bootstrap a new Prisma 2 project

You can bootstrap a new Prisma 2 project by using the npx command as follows:

$ npx prisma2 init server

Alternatively, you can install prisma2 CLI globally and run the init command. The do the following:

$ yarn global add prisma2 // or npm install --global prisma2 $ prisma2 init server

Run the interactive prisma2 init flow & select boilerplate

Select the following in the interactive prompts:

Select Starter Kit

Select JavaScript

Select GraphQL API

Select SQLite

Once terminated, the init command will have created an initial project setup in the server/ folder.

Now open the schema.prisma file and replace it with the following:

generator photon { provider = "photonjs" } datasource db { provider = "sqlite" url = "file:dev.db" } model Habit { id String @default(cuid()) @id name String @unique streak Int }

schema.prisma contains the data model as well as the configuration options.

Here, we specify that we want to connect to the SQLite datasource called dev.db as well as target code generators like photonjs generator.

Then we define the data model Habit, which consists of id, name and streak.

id is a primary key of type String with a default value of cuid().

name is of type String, but with a constraint that it must be unique.

streak is of type Int.

The seed.js file should look like this:

const { Photon } = require('@generated/photon') const photon = new Photon() async function main() { const workout = await photon.habits.create({ data: { name: 'Workout', streak: 49, }, }) const running = await photon.habits.create({ data: { name: 'Running', streak: 245, }, }) const cycling = await photon.habits.create({ data: { name: 'Cycling', streak: 77, }, }) const meditation = await photon.habits.create({ data: { name: 'Meditation', streak: 60, }, }) console.log({ workout, running, cycling, meditation, }) } main() .catch(e => console.error(e)) .finally(async () => { await photon.disconnect() })

This file creates all kinds of new habits and adds it to the SQLite database.

Now go inside the src/index.js file and remove its contents. We'll start adding content from scratch.

First go ahead and import the necessary packages and declare some constants:

const { GraphQLServer } = require('graphql-yoga') const { makeSchema, objectType, queryType, mutationType, idArg, stringArg, } = require('nexus') const { Photon } = require('@generated/photon') const { nexusPrismaPlugin } = require('nexus-prisma')

Now let’s declare our Habit model just below it:

const Habit = objectType({ name: 'Habit', definition(t) { t.model.id() t.model.name() t.model.streak() }, })

We make use of objectType from the nexus package to declare Habit.

The name parameter should be the same as defined in the schema.prisma file.

The definition function lets you expose a particular set of fields wherever Habit is referenced. Here, we expose id, name and streak field.

If we expose only the id and name fields, only those two will get exposed wherever Habit is referenced.

Below that, paste the Query constant:

const Query = queryType({ definition(t) { t.crud.habit() t.crud.habits() // t.list.field('habits', { // type: 'Habit', // resolve: (_, _args, ctx) => { // return ctx.photon.habits.findMany() // }, // }) }, })

We make use of queryType from the nexus package to declare Query.

The Photon generator generates an API that exposes CRUD functions on the Habit model. This is what allows us to expose t.crud.habit() and t.crud.habits() method.

t.crud.habit() allows us to query any individual habit by its id or by its name. t.crud.habits() simply returns all the habits.

Alternatively, t.crud.habits() can also be written as:

t.list.field('habits', { type: 'Habit', resolve: (_, _args, ctx) => { return ctx.photon.habits.findMany() }, })

Both the above code and t.crud.habits() will give the same results.

In the above code, we make a field named habits. The return type is Habit. We then call ctx.photon.habits.findMany() to get all the habits from our SQLite database.

Note that the name of the habits property is auto-generated using the pluralize package. It's therefore recommended practice to name our models singular — that is, Habit and not Habits.

We use the findMany method on habits, which returns a list of objects. We find all the habits as we have mentioned no condition inside of findMany. You can learn more about how to add conditions inside of findMany here.

Below Query, paste Mutation as follows:

const Mutation = mutationType({ definition(t) { t.crud.createOneHabit({ alias: 'createHabit' }) t.crud.deleteOneHabit({ alias: 'deleteHabit' }) t.field('incrementStreak', { type: 'Habit', args: { name: stringArg(), }, resolve: async (_, { name }, ctx) => { const habit = await ctx.photon.habits.findOne({ where: { name, }, }) return ctx.photon.habits.update({ data: { streak: habit.streak + 1, }, where: { name, }, }) }, }) }, })

Mutation uses mutationType from the nexus package.

The CRUD API here exposes createOneHabit and deleteOneHabit.

createOneHabit, as the name suggests, creates a habit whereas deleteOneHabit deletes a habit.

createOneHabit is aliased as createHabit, so while calling the mutation we call createHabit rather than calling createOneHabit.

Similarly, we call deleteHabit instead of deleteOneHabit.

Finally, we create a field named incrementStreak, which increments the streak of a habit. The return type is Habit. It takes an argument name as specified in the args field of type String. This argument is received in the resolve function as the second argument. We find the habit by calling ctx.photon.habits.findOne() while passing in the name parameter in the where clause. We need this to get our current streak. Then finally we update the habit by incrementing the streak by 1.

Below Mutation, paste the following:

const photon = new Photon() new GraphQLServer({ schema: makeSchema({ types: [Query, Mutation, Habit], plugins: [nexusPrismaPlugin()], }), context: { photon }, }).start(() => console.log( `🚀 Server ready at: http://localhost:4000\n⭐️ See sample queries: http://pris.ly/e/js/graphql#5-using-the-graphql-api`, ), ) module.exports = { Habit }

We use the makeSchema method from the nexus package to combine our model Habit, and add Query and Mutation to the types array. We also add nexusPrismaPlugin to our plugins array. Finally, we start our server at localhost:4000. Port 4000 is the default port for graphql-yoga. You can change the port as suggested here.

Let's start the server now. But first, we need to make sure our latest schema changes are written to the node_modules/@generated/photon directory. This happens when you run prisma2 generate.

If you haven't installed prisma2 globally, you'll have to replace prisma2 generate with ./node_modules/.bin/prisma2 generate. Then we need to migrate our database to create tables.

The post Building a Habit Tracker with Prisma, Chakra UI, and React appeared first on SitePoint.

by Akshay Kadam via SitePoint https://ift.tt/2YaQ5v2

#CSS3 #HTML5 Branding #HTML5 Weekly #HTMLl5 demos #Javascript Branding #Javascript Weekly #Mobile #Mo

0 notes

holytheoristtastemaker · 5 years ago

Link

One of the most important things which is also often neglected by developers - the performance. One of the key focus area for the 1.0 release was making it blazingly fast ⚡

TypeGraphQL is basically an abstraction layer built on top of the reference GraphQL implementation for JavaScript - graphql-js. To measure the overhead of the abstraction, a few demo examples were made to compare it against the "bare metal" - using raw graphql-js library.

It turned out that in the most demanding cases like returning an array of 25 000 nested objects, the old version 0.17 was even about 5 times slower!

library execution time TypeGraphQL v0.17 1253.28 ms graphql-js 265.52 ms

After profiling the code and finding all the root causes (like always using async execution path), the overhead was reduced from 500% to just 17% in v1.0.0! By using simpleResolvers it can be reduced even further, up to 13%:

execution time graphql-js 265.52 ms TypeGraphQL v1.0 310.36 ms with "simpleResolvers" 299.61 ms with a global middleware 1267.82 ms

Such small overhead is much easier to accept than the initial 500%! More info about how to enable the performance optimizations in the more complex cases can be found in the docs 📖.

Schema isolation

This is another feature that is not visible from the first sight but gives new possibilities like splitting the schema to public and private ones 👀

In 0.17.x and before, the schema was built from all the metadata collected by evaluating the TypeGraphQL decorators. The drawback of this approach was the schema leaks - every subsequent calls of buildSchema was returning the same schema which was combined from all the types and resolvers that could be find in the metadata storage.

In TypeGraphQL 1.0 it's no longer true! The schemas are now isolated which means that the buildSchema call takes theresolvers array from options and emit only the queries, mutation and types that are related to those resolvers.

const firstSchema = await buildSchema({ resolvers: [FirstResolver], }); const secondSchema = await buildSchema({ resolvers: [SecondResolver], });

So just by modifying the resolvers option we can have different sets of operations exposed in the GraphQL schemas! Proper isolation also makes serverless development easier as it allows to get rid of the "Schema must contain uniquely named types" errors and others.

Directives and extensions

This two new features are two complementary ways to put some metadata about the schema items.

GraphQL directives though the syntax might remind the TS decorators, as "a directive is an identifier preceded by a @ character", but in fact, they are a purely Schema Definition Language feature. Apart from the metadata capabilities, they can also modify the schema and e.g. generate the connection type for pagination purposes. Basically, the looks like this:

type Query { foobar: String! @auth(requires: USER) }

To apply them, we just need to put the @Directive decorator above and supply the string argument, e.g.:

@Resolver() class FooBarResolver { @Directive("@auth(requires: USER)") @Query() foobar(): string { return "foobar"; } }

However, on the other side we have the GraphQL extensions which are the JS way to achieve the same goal. It's the recommended way of putting the metadata about the types when applying some custom logic.

To declare the extensions for type or selected field, we need to use @Extensionsdecorator, e.g.:

@ObjectType() class Foo { @Extensions({ roles: [Role.User] }) @Field() bar: string; }

We can then read that metadata in the resolvers or middlewares, just by exploring the GraphQLResolveInfo object, e.g.:

export const ExtensionsMiddleware: MiddlewareFn = async ({ info }, next) => { const { extensions } = info.parentType.getFields()[info.fieldName]; console.log(extensions?.roles); // log the metadata return next(); };

More info about directives and extensions features can be found in docs 📖

Resolvers and arguments for interface fields

The last thing that was preventing TypeGraphQL from being fully GraphQL compliant thus blocking the 1.0 release - an ability to provide interface fields resolvers implementations and declare its arguments.

Basically, we can define resolvers for the interface fields using the same syntax we would use in case of the @ObjectType, e.g.:

@InterfaceType() abstract class IPerson { @Field() avatar(@Arg("size") size: number): string { return `http://i.pravatar.cc/${size}`; } }

...with only a few exceptions for cases like abstract methods and inheritance, which you can read about in the docs.

More descriptive errors messages

One of the most irritating issues for newcomers were the laconic error messages that haven't provided enough info to easily find the mistakes in the code.

Messages like "Cannot determine GraphQL input type for users" or even the a generic "Generating schema error" were clearly not helpful enough while searching for the place where the flaws were located.

Now, when the error occurs, it is broadly explained, why it happened and what could we do to fix that, e.g.:

Unable to infer GraphQL type from TypeScript reflection system. You need to provide explicit type for argument named 'filter' of 'getUsers' of 'UserResolver' class.

or:

Some errors occurred while generating GraphQL schema: Interface field 'IUser.accountBalance' expects type 'String!' but 'Student.accountBalance' is of type 'Float'

That should allow developers to safe tons of time and really speed up the development 🏎

Transforming nested inputs and arrays

In the previous releases, an instance of the input type class was created only on the first level of inputs nesting. So, in cases like this:

@InputType() class SampleInput { @Field() sampleStringField: string; @Field() nestedField: SomeNestedInput; } @Resolver() class SampleResolver { @Query() sampleQuery(@Arg("input") input: SampleInput): boolean { return input.nestedField instanceof SomeNestedInput; } }

the nestedField property of input was just a plain Object, not an instance of the SomeNestedInput class. That behavior was producing some unwanted issues, including limited support for inputs and args validation.

Since 1.0 release, it's no longer an issue and all the nested args and inputs are properly transformed to the corresponding input type classes instances, even including deeply nested arrays

0 notes

riichardwilson · 5 years ago

Text

Understanding Client-Side GraphQl With Apollo-Client In React Apps

About The Author

Blessing Krofegha is a Software Engineer Based in Lagos Nigeria, with a burning desire to contribute to making the web awesome for all, by writing and building … More about Blessing …

Ever tried interacting with a GraphQL server in a client-side application and felt like giving up even before getting anywhere? Ever declined an invitation to join a code base that requires working with GraphQL API because you had no idea? Ever felt like the only front-end engineer who hasn’t learned how to consume GraphQL APIs? If you answered yes to any of these questions, then this tutorial is for you. We’ll be taking a closer look at a few basics of GraphQL and Apollo Client, as well as how to work with both of them. By the end, we’ll have built a pet shop app that uses Apollo Client. Then, you can go on to build your next project.

According to State of JavaScript 2019, 38.7% of developers would like to use GraphQL, while 50.8% of developers would like to learn GraphQL.

Being a query language, GraphQL simplifies the workflow of building a client application. It removes the complexity of managing API endpoints in client-side apps because it exposes a single HTTP endpoint to fetch the required data. Hence, it eliminates overfetching and underfetching of data, as in the case of REST.

But GraphQL is just a query language. In order to use it easily, we need a platform that does the heavy lifting for us. One such platform is Apollo.

The Apollo platform is an implementation of GraphQL that transfers data between the cloud (the server) to the UI of your app. When you use Apollo Client, all of the logic for retrieving data, tracking, loading, and updating the UI is encapsulated by the useQuery hook (as in the case of React). Hence, data fetching is declarative. It also has zero-configuration caching. Just by setting up Apollo Client in your app, you get an intelligent cache out of the box, with no additional configuration required.

Apollo Client is also interoperable with other frameworks, such as Angular, Vue.js, and React.

Note: This tutorial will benefit those who have worked with RESTful or other forms of APIs in the past on the client-side and want to see whether GraphQL is worth taking a shot at. This means you should have worked with an API before; only then will you be able to understand how beneficial GraphQL could be to you. While we will be covering a few basics of GraphQL and Apollo Client, a good knowledge of JavaScript and React Hooks will come in handy.

GraphQL Basics

This article isn’t a complete introduction to GraphQL, but we will define a few conventions before continuing.

What Is GraphQL?

GraphQL is a specification that describes a declarative query language that your clients can use to ask an API for the exact data they want. This is achieved by creating a strong type schema for your API, with ultimate flexibility. It also ensures that the API resolves data and that client queries are validated against a schema. This definition means that GraphQL contains some specifications that make it a declarative query language, with an API that is statically typed (built around Typescript) and making it possible for the client to leverage those type systems to ask the API for the exact data it wants.

So, if we created some types with some fields in them, then, from the client-side, we could say, “Give us this data with these exact fields”. Then the API will respond with that exact shape, just as if we were using a type system in a strongly typed language. You can learn more in my Typescript article.

Let’s look at some conventions of GraphQl that will help us as we continue.

The Basics

Operations In GraphQL, every action performed is called an operation. There are a few operations, namely:

Query This operation is concerned with fetching data from the server. You could also call it a read-only fetch.

Mutation This operation involves creating, updating, and deleting data from a server. It is popularly called a CUD (create, update, and delete) operation.

Subscriptions This operation in GraphQL involves sending data from a server to its clients when specific events take place. They are usually implemented with WebSockets.

In this article, we will be dealing only with query and mutation operations.

Operation names There are unique names for your client-side query and mutation operations.

Variables and arguments Operations can define arguments, very much like a function in most programming languages. Those variables can then be passed to query or mutation calls inside the operation as arguments. Variables are expected to be given at runtime during the execution of an operation from your client.

Aliasing This is a convention in client-side GraphQL that involves renaming verbose or vague field names with simple and readable field names for the UI. Aliasing is necessary in use cases where you don’t want to have conflicting field names.

GraphQL basic conventions. (Large preview)

What Is Client-Side GraphQL?

When a front-end engineer builds UI components using any framework, like Vue.js or (in our case) React, those components are modeled and designed from a certain pattern on the client to suit the data that will be fetched from the server.

One of the most common problems with RESTful APIs is overfetching and underfetching. This happens because the only way for a client to download data is by hitting endpoints that return fixed data structures. Overfetching in this context means that a client downloads more information than is required by the app.

In GraphQL, on the other hand, you’d simply send a single query to the GraphQL server that includes the required data. The server would then respond with a JSON object of the exact data you’ve requested — hence, no overfetching. Sebastian Eschweiler explains the differences between RESTful APIs and GraphQL.

Client-side GraphQL is a client-side infrastructure that interfaces with data from a GraphQL server to perform the following functions:

It manages data by sending queries and mutating data without you having to construct HTTP requests all by yourself. You can spend less time plumbing data and more time building the actual application.

It manages the complexity of a cache for you. So, you can store and retrieve the data fetched from the server, without any third-party interference, and easily avoid refetching duplicate resources. Thus, it identifies when two resources are the same, which is great for a complex app.

It keeps your UI consistent with Optimistic UI, a convention that simulates the results of a mutation (i.e. the created data) and updates the UI even before receiving a response from the server. Once the response is received from the server, the optimistic result is thrown away and replaced with the actual result.

For further information about client-side GraphQL, spare an hour with the cocreator of GraphQL and other cool folks on GraphQL Radio.

What Is Apollo Client?

Apollo Client is an interoperable, ultra-flexible, community-driven GraphQL client for JavaScript and native platforms. Its impressive features include a robust state-management tool (Apollo Link), a zero-config caching system, a declarative approach to fetching data, easy-to-implement pagination, and the Optimistic UI for your client-side application.

Apollo Client stores not only the state from the data fetched from the server, but also the state that it has created locally on your client; hence, it manages state for both API data and local data.

It’s also important to note that you can use Apollo Client alongside other state-management tools, like RedUX, without conflict. Plus, it’s possible to migrate your state management from, say, Redux to Apollo Client (which is beyond the scope of this article). Ultimately, the main purpose of Apollo Client is to enable engineers to query data in an API seamlessly.

Features of Apollo Client

Apollo Client has won over so many engineers and companies because of its extremely helpful features that make building modern robust applications a breeze. The following features come baked in:

Caching Apollo Client supports caching on the fly.

Optimistic UI Apollo Client has cool support for the Optimistic UI. It involves temporarily displaying the final state of an operation (mutation) while the operation is in progress. Once the operation is complete, the real data replaces the optimistic data.

Pagination Apollo Client has built-in functionality that makes it quite easy to implement pagination in your application. It takes care of most of the technical headaches of fetching a list of data, either in patches or at once, using the fetchMore function, which comes with the useQuery hook.

In this article, we will look at a selection of these features.

Enough of the theory. Tighten your seat belt and grab a cup of coffee to go with your pancakes, as we get our hands dirty.

Building Our Web App

This project is inspired by Scott Moss.

We will be building a simple pet shop web app, whose features include:

fetching our pets from the server-side;

creating a pet (which involves creating the name, type of pet, and image);

using the Optimistic UI;

using pagination to segment our data.

To begin, clone the repository, ensuring that the starter branch is what you’ve cloned.

Getting Started

Install the Apollo Client Developer Tools extension for Chrome.

Using the command-line interface (CLI), navigate to the directory of the cloned repository, and run the command to get all dependencies: npm install.

Run the command npm run app to start the app.

While still in the root folder, run the command npm run server. This will start our back-end server for us, which we’ll use as we proceed.

The app should open up in a configured port. Mine is http://localhost:1234/; yours is probably something else.

If everything worked well, your app should look like this:

Cloned starter branch UI. (Large preview)

You’ll notice that we’ve got no pets to display. That’s because we haven’t created such functionality yet.

If you’ve installed Apollo Client Developer Tools correctly, open up the developer tools and click on the tray icon. You’ll see “Apollo” and something like this:

Apollo Client Developer Tools. (Large preview)

Like the RedUX and React developer tools, we will be using Apollo Client Developer Tools to write and test our queries and mutations. The extension comes with the GraphQL Playground.

Fetching Pets

Let’s add the functionality that fetches pets. Move over to client/src/client.js. We’ll be writing Apollo Client, linking it to an API, exporting it as a default client, and writing a new query.

Copy the following code and paste it in client.js:

import { ApolloClient } from 'apollo-client' import { InMemoryCache } from 'apollo-cache-inmemory' import { HttpLink } from 'apollo-link-http' const link = new HttpLink({ uri: 'https://localhost:4000/' }) const cache = new InMemoryCache() const client = new ApolloClient({ link, cache }) export default client

Here’s an explanation of what is happening above:

ApolloClient This will be the function that wraps our app and, thus, interfaces with the HTTP, caches the data, and updates the UI.

InMemoryCache This is the normalized data store in Apollo Client that helps with manipulating the cache in our application.

HttpLink This is a standard network interface for modifying the control flow of GraphQL requests and fetching GraphQL results. It acts as middleware, fetching results from the GraphQL server each time the link is fired. Plus, it’s a good substitute for other options, like Axios and window.fetch.

We declare a link variable that is assigned to an instance of HttpLink. It takes a uri property and a value to our server, which is https://localhost:4000/.

Next is a cache variable that holds the new instance of InMemoryCache.

The client variable also takes an instance of ApolloClient and wraps the link and cache.

Lastly, we export the client so that we can use it across the application.

Before we get to see this in action, we’ve got to make sure that our entire app is exposed to Apollo and that our app can receive data fetched from the server and that it can mutate that data.

To achieve this, let’s head over to client/src/index.js:

import React from 'react' import ReactDOM from 'react-dom' import { BrowserRouter } from 'react-router-dom' import { ApolloProvider } from '@apollo/react-hooks' import App from './components/App' import client from './client' import './index.css' const Root = () => ( <BrowserRouter> <ApolloProvider client={client}> <App /> </ApolloProvider> </BrowserRouter> ); ReactDOM.render(<Root />, document.getElementById('app')) if (module.hot) { module.hot.accept() }

As you’ll notice in the highlighted code, we’ve wrapped the App component in ApolloProvider and passed the client as a prop to the client. ApolloProvider is similar to React’s Context.Provider. It wraps your React app and places the client in context, which allows you to access it from anywhere in your component tree.

To fetch our pets from the server, we need to write queries that request the exact fields that we want. Head over to client/src/pages/Pets.js, and copy and paste the following code into it:

import React, {useState} from 'react' import gql from 'graphql-tag' import { useQuery, useMutation } from '@apollo/react-hooks' import PetsList from '../components/PetsList' import NewPetModal from '../components/NewPetModal' import Loader from '../components/Loader' const GET_PETS = gql` query getPets { pets { id name type img } } `; export default function Pets () { const [modal, setModal] = useState(false) const { loading, error, data } = useQuery(GET_PETS); if (loading) return <Loader />; if (error) return <p>An error occured!</p>; const onSubmit = input => { setModal(false) } if (modal) { return <NewPetModal onSubmit={onSubmit} onCancel={() => setModal(false)} /> } return ( <div className="page pets-page"> <section> <div className="row betwee-xs middle-xs"> <div className="col-xs-10"> <h1>Pets</h1> </div> <div className="col-xs-2"> <button onClick={() => setModal(true)}>new pet</button> </div> </div> </section> <section> <PetsList pets={data.pets}/> </section> </div> ) }

With a few bits of code, we are able to fetch the pets from the server.

What Is gql?

It’s important to note that operations in GraphQL are generally JSON objects written with graphql-tag and with backticks.

gql tags are JavaScript template literal tags that parse GraphQL query strings into the GraphQL AST (abstract syntax tree).

Query operations In order to fetch our pets from the server, we need to perform a query operation.

Because we’re making a query operation, we needed to specify the type of operation before naming it.

The name of our query is GET_PETS. It’s a naming convention of GraphQL to use camelCase for field names.

The name of our fields is pets. Hence, we specify the exact fields that we need from the server (id, name, type, img).

useQuery is a React hook that is the basis for executing queries in an Apollo application. To perform a query operation in our React component, we call the useQuery hook, which was initially imported from @apollo/react-hooks. Next, we pass it a GraphQL query string, which is GET_PETS in our case.

When our component renders, useQuery returns an object response from Apollo Client that contains loading, error, and data properties. Thus, they are destructured, so that we can use them to render the UI.

useQuery is awesome. We don’t have to include async-await. It’s already taken care of in the background. Pretty cool, isn’t it?

loading This property helps us handle the loading state of the application. In our case, we return a Loader component while our application loads. By default, loading is false.

error Just in case, we use this property to handle any error that might occur.

data This contains our actual data from the server.

Lastly, in our PetsList component, we pass the pets props, with data.pets as an object value.

At this point, we have successfully queried our server.

To start our application, let’s run the following command:

Start the client app. Run the command npm run app in your CLI.

Start the server. Run the command npm run server in another CLI.

VScode CLI partitioned to start both the client and the server. (Large preview)

If all went well, you should see this:

Pets queried from the server.

Mutating Data

Mutating data or creating data in Apollo Client is almost the same as querying data, with very slight changes.

Still in client/src/pages/Pets.js, let’s copy and paste the highlighted code:

.... const GET_PETS = gql` query getPets { pets { id name type img } } `; const NEW_PETS = gql` mutation CreateAPet($newPet: NewPetInput!) { addPet(input: $newPet) { id name type img } } `; const Pets = () => { const [modal, setModal] = useState(false) const { loading, error, data } = useQuery(GET_PETS); const [createPet, newPet] = useMutation(NEW_PETS); const onSubmit = input => { setModal(false) createPet({ variables: { newPet: input } }); } if (loading || newPet.loading) return <Loader />; if (error || newPet.error) return <p>An error occured</p>; if (modal) { return <NewPetModal onSubmit={onSubmit} onCancel={() => setModal(false)} /> } return ( <div className="page pets-page"> <section> <div className="row betwee-xs middle-xs"> <div className="col-xs-10"> <h1>Pets</h1> </div> <div className="col-xs-2"> <button onClick={() => setModal(true)}>new pet</button> </div> </div> </section> <section> <PetsList pets={data.pets}/> </section> </div> ) } export default Pets

To create a mutation, we would take the following steps.

1. mutation

To create, update, or delete, we need to perform the mutation operation. The mutation operation has a CreateAPet name, with one argument. This argument has a $newPet variable, with a type of NewPetInput. The ! means that the operation is required; thus, GraphQL won’t execute the operation unless we pass a newPet variable whose type is NewPetInput.

2. addPet

The addPet function, which is inside the mutation operation, takes an argument of input and is set to our $newPet variable. The field sets specified in our addPet function must be equal to the field sets in our query. The field sets in our operation are:

name

type

img

3. useMutation

The useMutation React hook is the primary API for executing mutations in an Apollo application. When we need to mutate data, we call useMutation in a React component and pass it a GraphQL string (in our case, NEW_PETS).

When our component renders useMutation, it returns a tuple (that is, an ordered set of data constituting a record) in an array that includes:

a mutate function that we can call at any time to execute the mutation;

an object with fields that represent the current status of the mutation’s execution.

The useMutation hook is passed a GraphQL mutation string (which is NEW_PETS in our case). We destructured the tuple, which is the function (createPet) that will mutate the data and the object field (newPets).

4. createPet

In our onSubmit function, shortly after the setModal state, we defined our createPet. This function takes a variable with an object property of a value set to { newPet: input }. The input represents the various input fields in our form (such as name, type, etc.).

With that done, the outcome should look like this:

Mutation without instant update.

If you observe the GIF closely, you’ll notice that our created pet doesn’t show up instantly, only when the page is refreshed. However, it has been updated on the server.

The big question is, why doesn’t our pet update instantly? Let’s find out in the next section.

Caching In Apollo Client

The reason our app doesn’t update automatically is that our newly created data doesn’t match the cache data in Apollo Client. So, there is a conflict as to what exactly it needs to be updated from the cache.

Simply put, if we perform a mutation that updates or deletes multiple entries (a node), then we are responsible for updating any queries referencing that node, so that it modifies our cached data to match the modifications that a mutation makes to our back-end data.

Keeping Cache In Sync

There are a few ways to keep our cache in sync each time we perform a mutation operation.

The first is by refetching matching queries after a mutation, using the refetchQueries object property (the simplest way).

Note: If we were to use this method, it would take an object property in our createPet function called refetchQueries, and it would contain an array of objects with a value of the query: refetchQueries: [{ query: GET_PETS }].

Because our focus in this section isn’t just to update our created pets in the UI, but to manipulate the cache, we won’t be using this method.

The second approach is to use the update function. In Apollo Client, there’s an update helper function that helps modify the cache data, so that it syncs with the modifications that a mutation makes to our back-end data. Using this function, we can read and write to the cache.

Updating The Cache

Copy the following highlighted code, and paste it in client/src/pages/Pets.js:

...... const Pets = () => { const [modal, setModal] = useState(false) const { loading, error, data } = useQuery(GET_PETS); const [createPet, newPet] = useMutation(NEW_PETS, { update(cache, { data: { addPet } }) { const data = cache.readQuery({ query: GET_PETS }); cache.writeQuery({ query: GET_PETS, data: { pets: [addPet, ...data.pets] }, }); }, } ); .....

The update function receives two arguments:

The first argument is the cache from Apollo Client.

The second is the exact mutation response from the server. We destructure the data property and set it to our mutation (addPet).

Next, to update the function, we need to check for what query needs to be updated (in our case, the GET_PETS query) and read the cache.

Secondly, we need to write to the query that was read, so that it knows we’re about to update it. We do so by passing an object that contains a query object property, with the value set to our query operation (GET_PETS), and a data property whose value is a pet object and that has an array of the addPet mutation and a copy of the pet’s data.

If you followed these steps carefully, you should see your pets update automatically as you create them. Let’s take a look at the changes:

Pets updates instantly.

Optimistic UI

A lot of people are big fans of loaders and spinners. There’s nothing wrong with using a loader; there are perfect use cases where a loader is the best option. I’ve written about loaders versus spinners and their best use cases.

Loaders and spinners indeed play an important role in UI and UX design, but the arrival of Optimistic UI has stolen the spotlight.

What Is Optimistic UI?

Optimistic UI is a convention that simulates the results of a mutation (created data) and updates the UI before receiving a response from the server. Once the response is received from the server, the optimistic result is thrown away and replaced with the actual result.

In the end, an optimistic UI is nothing more than a way to manage perceived performance and avoid loading states.

Apollo Client has a very interesting way of integrating the Optimistic UI. It gives us a simple hook that allows us to write to the local cache after mutation. Let’s see how it works!

Step 1

Head over to client/src/client.js, and add only the highlighted code.

import { ApolloClient } from 'apollo-client' import { InMemoryCache } from 'apollo-cache-inmemory' import { HttpLink } from 'apollo-link-http' import { setContext } from 'apollo-link-context' import { ApolloLink } from 'apollo-link' const http = new HttpLink({ uri: "http://localhost:4000/" }); const delay = setContext( request => new Promise((success, fail) => { setTimeout(() => { success() }, 800) }) ) const link = ApolloLink.from([ delay, http ]) const cache = new InMemoryCache() const client = new ApolloClient({ link, cache }) export default client

The first step involves the following:

We import setContext from apollo-link-context. The setContext function takes a callback function and returns a promise whose setTimeout is set to 800ms, in order to create a delay when a mutation operation is performed.

The ApolloLink.from method ensures that the network activity that represents the link (our API) from HTTP is delayed.

Step 2

The next step is using the Optimistic UI hook. Slide back to client/src/pages/Pets.js, and add only the highlighted code below.

..... const Pets = () => { const [modal, setModal] = useState(false) const { loading, error, data } = useQuery(GET_PETS); const [createPet, newPet] = useMutation(NEW_PETS, { update(cache, { data: { addPet } }) { const data = cache.readQuery({ query: GET_PETS }); cache.writeQuery({ query: GET_PETS, data: { pets: [addPet, ...data.pets] }, }); }, } ); const onSubmit = input => { setModal(false) createPet({ variables: { newPet: input }, optimisticResponse: { __typename: 'Mutation', addPet: { __typename: 'Pet', id: Math.floor(Math.random() * 10000 + ''), name: input.name, type: input.type, img: 'https://via.placeholder.com/200' } } }); } .....

The optimisticResponse object is used if we want the UI to update immediately when we create a pet, instead of waiting for the server response.

The code snippets above include the following:

__typename is injected by Apollo into the query to fetch the type of the queried entities. Those types are used by Apollo Client to build the id property (which is a symbol) for caching purposes in apollo-cache. So, __typename is a valid property of the query response.

The mutation is set as the __typename of optimisticResponse.

Just as earlier defined, our mutation’s name is addPet, and the __typename is Pet.

Next are the fields of our mutation that we want the optimistic response to update:

id Because we don’t know what the ID from the server will be, we made one up using Math.floor.

name This value is set to input.name.

type The type’s value is input.type.

img Now, because our server generates images for us, we used a placeholder to mimic our image from the server.

This was indeed a long ride. If you got to the end, don’t hesitate to take a break from your chair with your cup of coffee.

Let’s take a look at our outcome. The supporting repository for this project is on GitHub. Clone and experiment with it.

Final result of our app.

Conclusion

The amazing features of Apollo Client, such as the Optimistic UI and pagination, make building client-side apps a reality.

While Apollo Client works very well with other frameworks, such as Vue.js and Angular, React developers have Apollo Client Hooks, and so they can’t help but enjoy building a great app.

In this article, we’ve only scratched the surface. Mastering Apollo Client demands constant practice. So, go ahead and clone the repository, add pagination, and play around with the other features it offers.

Please do share your feedback and experience in the comments section below. We can also discuss your progress on Twitter. Cheers!

References

(ks, ra, al, yk, il)

Website Design & SEO Delray Beach by DBL07.co

Delray Beach SEO

source http://www.scpie.org/understanding-client-side-graphql-with-apollo-client-in-react-apps/ source https://scpie.tumblr.com/post/625015311855419392

0 notes

scpie · 5 years ago